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FOREWORD 


The Software Engineering Laboratory (SEL) is an organization 
sponsored by the National Aeronautics and Space 
Administration/Goddard Space Flight Center (NASA/GSFC) and 
created for the purpose of investigating the effectiveness 
of software engineering technologies when applied to the 
development of applications software. The SEL was created 
in 1977 and has three primary organizational members: 

NASA/GSFC (Systems Development and Analysis Branch) 

The University of Maryland (Computer Sciences Department) 
Computer Sciences Corporation (Flight Systems Operation) 

The goals of the SEL are (1) to understand the software 
development process in the GSFC environment; (2) to measure 
the effect of various methodologies, tools, and models on 
this process; and (3) to identify and then to apply success- 
ful development practices. The activities, findings, and 
recommendations of the SEL are recorded in the Software 
Engineering Laboratory Series, a continuing series of re- 
ports that includes this document. A version of this docu- 
ment was also issued as Computer Sciences Corporation 
document CSC/TM-83/6168 . 

The contributors to this document include 

Thomas Babst (Computer Sciences Corporation) 

Michael Rohleder (Computer Sciences Corporation) 

Frank McGarry (Goddard Space Flight Center) 

Single copies of this document can be obtained by writing to 

Frank E. McGarry 
Code 582.1 
NASA/GSFC 

Greenbelt, Md. 20771 


ABSTRACT 


This document is a glossary of terms used in the software 
Engineering Laboratory (SEL) . The terms are defined within 
the context of the software development environment for 
flight dynamics at Goddard Space Flight Center. The pur- 
poses of this document are to provide a concise reference 
for clarifying the language employed in SEL documents and 
data collection forms, establish standard definitions for 
use by SEL personel, and explain basic software engineering 
concepts . 
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SECTION 1 - INTRODUCTION 


The glossary of Software Engineering Laboratory (SEL) terms 
presents a comprehensive collection of frequently used soft- 
ware engineering terms and expressions. Its objectives are 
to 

• Provide a reference for clarifying the language of 
SEL documents and data collection forms 

• Establish standard definitions for use by SEL per- 
sonnel 

• Explain basic software engineering concepts 

The definitions provided in this document are consistent 
with the Institute of Electrical and Electronics Engineers 
(IEEE) publication Standard Glossary of Software Engineering 
Terminology (1983) . However, some variations were needed to 
accommodate local (SEL) usages. Definitions were compiled 
from many sources: SEL personnel, data collection forms, 

and documents. The Data and Analysis Center for Software 
(DACS) document Glossary of Terms (1981) was also examineu. 


SECTION 2 - SOFTWARE ENGINEERING TERMS 


acceptance testing 


adaptability 

adjusted lines of 
code 

algorithm 

analyzer 


archive 


argument 

array 

assemble 


Independent testing conducted to 
verify that all functional require- 
ments of a system have been satis- 
fied. The results . determine the 
acceptance or rejection of the soft- 
ware. 

A measure of the ease with which a 
program can be altered to fit differ- 
ing user and system constraints. 

See lines of code. 

A prescribed set of well-defined rules 
or processes for the solution of a 
problem . 

Computer software used as a tool that 
is applied to a program to provide 
analytical information; it breaks the 
program into identifiable segments and 
reports statistical information. This 
information can include execution fre- 
quency statistics,, program path 
analysis, and/or source code syntax 
analysis . 

Process involving the transfer of data 
or information from one source or vol- 
ume to another to provide a backup or 
alternate copy of the information for 
future use. 

Variable or expression passed to an 
operation or function as input or out- 
put . 

An ordered group or collection of 
variables, terms, or expressions. An 
array is usually dimensioned or in- 
dexed . 

To translate a program written in as- 
sembly language into machine lan- 
guage. The assembly language 
operation codes are substituted with 
machine language operation codes, and 
symbolic addresses are substituted 
with absolute, immediate, relocatable, 
or virtual addresses. 
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assignment 

statement 


attribute list 


baseline 


batch 


block diagram 


bug 

build 


calibration error 
certification test 


An expression or instruction used to 
assign values to specified variables 
or symbols. Includes all statements 
that change the' value of a variable as 
their main purpose; for example, READ 
statements. However, the assignment 
of the iteration counter in a DO 
statement is not included. 

A compiler-generated list of identi- 
fiers used by a program. The list 
includes type characteristics of iden- 
tifiers, source statements that define 
or use the identifiers, and the rela- 
tive storage location of the variables 
used in the program. 

A tree chart or hierarchical graph of 
a software design containing all 
components in the system. A connec- 
tion from a higher component to a 
lower one indicates that the higher 
component calls the lower one. 

Mode of operation of a computer in 
which the entire job is read into the 
machine before processing begins and 
in which there is no provision for 
interaction with the submitter during 
execution of the job. 

A diagram of a system or computer in 
which the principal parts are repre- 
sented by geometrical figures that 
show both the basic functions and the 
functional relationships among the 
parts . 

See defect. 

A functional subset of a more complex 
software development product. The 
"builds" approach to software develop- 
ment consists of developing a series 
of increasingly complete functional 
systems . 

An error in the gauge or tolerance of 
specifications . 

A formal demonstration to the customer 
showing that requirements have been 
met . 
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change 


clerical error 


code 

code and unit test 
code reading 


code walk-through 
coding 

cohesion 

command/control 

commission error 

compile 


complexity 


component 


A modification to requirements, de- 
sign, code, or documentation made to 
correct an error, improve system per- 
formance, add capability, improve ap- 
pearance, or implement a requirements 
change. 

An error made in the process of copy- 
ing an item from one format to another 
or from one medium to another, which 
involves no interpretation or semantic 
translation . 

A symbolic represen, cation of a func- 
tion composed of computer program 
statements . 

See implementation. 

Inspection of the source code by per- 
sons other than the creator of the 
code in an attempt to detect errors or 
to recommend coding improvements. 

See walk-through. 

Representing a function in a form that 
is meaningful to a computer system. 

See module strength. 

A class of software including programs 
used to generate satellite commands 
from the control center. 

An error made by including an incor- 
rect item that results in software 
containing a defect. 

To translate a computer program 
written in a high-level procedural 
language into a machine-language 
version . 

A measure of the difficulty of imple- 
menting or understanding a component, 
independent of the implementor's ex- 
perience; for example, the degree of 
interactions and number of dependen- 
cies among elements of a computer pro- 
gram. 

A named piece of a system; for ex- 
ample, a separately compilable func- 
tion, a functional subsystem, or a 
shared section of data such as a 
COMMON block . 
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computational 

error 


computer 

architecture 


confidence level 


configuration 

control 


configuration item 


control error 

configuration 

management 


control statement 

control structure 

convention 
cor rect ion 


Any error in which a value is computed 
by an incorrect mathematical expres- 
sion. 

The relationships between the parts of 
a computer system; the structural and 
functional definition of a computer as 
viewed in terms of its machine in- 
struction set and input/output cap- 
abilities . 

The probability that a given statement 
is correct; 100 percent means that the 
statement is invariably true. 

A methodology for controlling the con- 
tents of a software system; a way of 
monitoring the status of system com- 
ponents, preserving the integrity of 
released and developing versions of a 
software system, and controlling the 
effects of changes throughout the sys- 
tem. 

A group or collection of computer 
hardware or software elements that are 
treated as a unit for the purpose of 
configuration management. Configura- 
tion items may vary widely in com- 
plexity and size. 

See logic error. 

All activities related to controlling 
the contents of a software system: 
monitoring the status of system com- 
ponents, preserving the integrity of 
released and developing versions of a 
system, and controlling the effects of 
changes throughout the system. 

A statement that potentially alters 
the sequence of executed instructions; 
for example, GOTO, IF, RETURN, DO. 

A recurrent pattern of control state- 
ments; for example, sequence, itera- 
tion, selection. 

An agreed-upon method, notation, or 
form of presentation. 

A change made to correct an error. 
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cosmetic change 


cost estimation 

costing technique 

coupling 

criticality 

data 

data base 

data collection 

data definition 
language 

data dictionary 

data error 
data set 

data structure 
data type 
data validation 


A change in the source program made to 
improve clarity that has little effect 
on the performance of the program; for 
example, comment correction, movement 
of code that does not alter the imple- 
mented algorithm, or changing the name 
of a local variable. 

Prediction made before and during a 
project's life cycle of the amount of 
labor necessary to complete a task, 
the amount and potential costs of com- 
puter time required, etc. 

A method for determining the cost of 
developing a system or any particular 
part of a system. 

See module coupling. 

A measure of the degree of dependence 
of the whole on a part of a .system. 

A series or collection of measurements. 

(1) A set of data files that are 
logically related. 

(2) An organized system of storing 
data. 

The methods, forms, procedures, per- 
sonnel, and activity used in measure- 
ment . 

A special-purpose language used to de- 
fine data items in a data base and to 
create a data dictionary. 

Afile that describes the format of 
fields, values, and records in a data 
base . 

Any error in the use of a variable or 
data structure. 

A named collection of logically re- 
lated data items, arranged in a prede- 
scribed manner residing in a physical 
storage location, usually magnetic 
tape or disk. 

The logical relationship among the 
units of data in a data base. 

A set of attributes used to define a 
data item. 

The process of verifying the complete- 
ness and accuracy of data. 
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data base management 
system 

debugging 

defect 

design 

design language 

design phase 

- preliminary 


,i detailed 


A software system for managing a data 
base, usually consisting of a data 
definition language and a data access 
language , 

The process of locating and correcting 
software errors. 

An error in the design or implementa- 
tion of a program. One or more soft- 
ware defects exist in a system if a 
software change is required to meet 
specified or implied system perform- 
ance requirements, A defect may also 
be called a fault or bug, 

(1) The process of defining how a 
system is to be constructed, its 
components, interfaces among those 
components, and interfaces with 
the external environment to 
satisfy specified requirements. 

(2) The results of the design process. 

A formal language for representing the 
logic, control, and data flow of a 
software system, usually input to an 
analyzer program. 

The life cycle phase in which the 
structure of a system is planned and 
recorded . 

The specification of major functional 
subsystems, input/output interfaces, 
processing modes, and implementation 
strategy. The software system archi- 
tecture is defined, based on the re- 
quirements given in the functional 
specification and requirements docu- 
ment, and translated into software 
requirements in the requirements anal- 
ysis summary report. 

The extension of the system architec- 
ture defined in the preliminary design 
phase to the subroutine level. The 
preliminary design is elaborated by 
successive refinement techniques to 
produce a "code-to" specification for 
the system. 
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design reading 


design review 

design specification 
design verification 

i 

design walk-through 

development 

methodology 

development phase 

develops lines of 
cede 

discrepancy 

documentation 

driver 


dynamic allocation 
efficiency 


effort 


Inspection of the design by persons 
other than the creator of the design 
for the purpose of detecting defects, 
development standard violations and 
other problems. 

A formal meeting between customer and 
developer to determine that a proposed 
software configuration will satisfy 
performance specifications. 

A document describing the approved de- 
sign for a program. 

The formal examination or inspection 
of a software specification for the 
purpose of finding design errors and 
ambiguities . 

See walk-through. 

A systematic approach to the creation 
of software that specifies the activi- 
ties, products, verification, and com- 
pletion criteria for each phase of 
development. 

See life cycle. 

The total number of new lines of source 
code plus 20 percent of reused code. 

The difference between the intention 
of a specification and its actual im- 
plementation. 

Written material, other than source 
code statements, that describes a sys- 
tem or any of its components. 

A software component developed specif- 
ically to call other components; used 
in an informal testing technique dur- 
ing the implementation phase. 

The allocation of memory required by 
an operating program during its execu- 
tion phase rather than prior to execu- 
tion. 

The ratio of useful work performed to 
the total energy expended. Code is 
efficient to the extent that it ful- 
fills its purpose without wasting re- 
sources. 

The amount of resources, including 
staff and computer time, necessary to 
complete a particular project. 
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V 


element 

embedded system 


environment 


error 


error analysis 


error recovery 


A basic segment of a named piece of a 
system (component) . 

A dedicated computer system that is 
physically incorporated into a larger 
system whose primary function is not 
data processing; for example, an elec- 
tromechanical system. 

The combination of hardware and soft- 
ware used to develop, maintain, and/or 
execute software, including the com- 
puter, operating system, support li- 
braries, text editors, compiler, etc. 

(1) An internal condition that pre- 
vents a software system from suc- 
cessfully performing its intended 
function, 

(2) Human action that results in soft- 
ware containing a defect. Also 
see failure, calibration error, 
clerical error, commission error, 
omission error, initialization 
error, logic error, interface 
error, data error, and computa- 
tional error. 

The examination of errors with the 
purpose of tracing them to their 
sources and determining their effects. 

The ability of a system to resume 
processing rather than abort after an 
error . 


estimation parameter 
executable statement 
execution 
execution time 
external reference 

failure rate 


Any estimator or contributing factor 
to the process of estimation. 

Statement that changes the value of 
data or the state of a program. 

Performance by a computer of the in- 
structions in a program. 

The actual central processor time used 
in executing a program. 

A call to a function or subroutine 
that is outside the calling procram 
body. 

The number of failures occuring within 
a specified period of central process- 
ing unit time. Also see error rate. 
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failure, software 


fault 
f ile 

flight dynamics 
software 

flow chart 


form 

-• change report 

- component status 

- component 
summary 

- data base 
problem report 

- maintenance 
change report 

- project summary 

- resource summary 

- run analysis 

formal specification 


formal testing 


An unacceptable result produced during 
the operation of the computer pro- 
gram. Occurs when a fault is evoked 
by some input data. Also see error. 

See defect. 

A set of related records treated as a 
unit . 

Applications to support attitude deter- 
mination and control, maneuver plan- 
ning, orbit adjustment, and general 
mission analysis. 

A graphical representation of an al- 
gorithm in which symbols are used to 
represent operations, data, data flow, 
equipment, etc. 

Questionnaire used to record informa- 
tion about the software development 
process and/or software product. 

Records software change and error data 
during development. 

Records time expended for activities. 

Records the status of system compo- 
nents . 

Used to identify and initiate action 
on data base problems. 

Records software change and error data 
during maintenance. 

Used to classify the project and meas- 
ure development progress. 

Records expended resources. 

Used to monitor activities for which 
the computer is used. 

A specification technique based on a 
strict set of tules for describing the 
specification and usually involving 
the use of an unambiguously defined 
notation; for example, mathematical 
functions or formal program design 
language. 

Testing performed in accordance with 
customer-approved test plans. Veri- 
fies that the software system is op- 
erating as specified in the 
requirements. 
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format statement 

function 

functional 

specification 

Halstead measures 

hardest first 
hardware 

hardware reliability 

hierarchical input 
process output 

hierarchy 

high-level language 

historical 

identifier 


A source language statement that may 
accompany an input/output statement’ to 
specify the source or destination of 
the data and the arrangement of data 
items on the input or output record. 

A mathematical subprogram used to 
specify an input set, an output set, 
and the relationship between the two. 

A specification of a software component 
as a set of functions defining the 
output for any input. Emphasizes what 
a program is to do rather than how to 
do it. 

Measures developed by M. Halstead in 
his theory of "software science," 
based on basic elements of programming 
languages: operator, operand, length, 

volume, and language level. 

The development approach of designing 
or implementing the most difficult 
aspects of a system first. 

The physical and electronic components 
of a computer system including input/ 
output devices, CPU, memory, etc. 

A measure of the probability of a 
hardware system operating without 
failure, usually measured as mean time 
to failure. 

A software design technique that de- 
fines each component in terms of a 
transformation from an input data set 
to an output data set, usually repre- 
sented in graphic form. 

A ranked series of elements, such as 
tasks, programs, people, functions, 
etc . 

A programming language that does not 
reflect the structure of any one given 
computer or that of any given class of 
computers . 

Of or pertaining to data archives on 
past experience with particular proj- 
ects. 

A symbol whose purpose is to identify, 
indicate, name, or 1 •’'ate a data 
structure or procedu*. ~-ntry point. 
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implementation 

informal testing 

initialization 

error 

input/output 

instruction 

integration 

integration test 

interactive 

interface 

interface error 
interface testing 
interpret 


Life cycle phase in which code is de- 
veloped or modified to meet design 
specifications. Each module (or unit) 
is integrated into the system and 
tested to ensure that the newly added 
capabilities function correctly. 

Testing involving no formal, written 
test plan. 

Any error resulting from an incorrectly 
initialized variable or failure to 
initialize a variable. 

Usually refers to data or hardware 
processes involving the transfer of 
information to or from computer main 
memory. 

See executable statement. 

The combination of subunits into an 
overall unit or system by means of 
interfacing . 

A test of several modules to check 
that the interfaces are implemented 
correctly. 

A mode of computer operation in which 
each line of input is immediately 
processed? allows communication with 
the program during its execution. 

The set of data and control informa- 
tion passed between two or more pro- 
grams or segments of programs and the 
assumptions made by each program about 
how the others operate. 

Any error of data exchange within a 
system (internal); any error of data 
exchange between some module and an 
entity outside the system (external) . 

Validation that a module or set of 
modules operates within agreed inter- 
face specifications to ensure proper 
data and logical communications. 

To translate and execute a high-level 
language program by translating each 
statement to a corresponding sequence 
of machine operations and executing 
them before proceeding to the next 
statement . 
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interrupt 


i teration 


i terative 
enhancement 


independent 
verification and 
validation 

job 

job control language 
librarian 

life cycle 


lines of code 
- adjusted 


Any stopping of a process by an ex- 
ternal event in such a way that it can 
be resumed. 

Repetition of a sequence of instruc- 
tions until a specified set of condi- 
tions is satisfied. 

The design or implementation of suc- 
cessive versions, each producing a 
usable subset of the final product, 
until the entire system is fully de- 
veloped . 

A software quality assurance technique 
in which an independent team reviews 
and tests the software while it is 
under development. 

A unit of computer work consisting of 
one or more steps such as compilation, 
assembly, or utility runs. 

A program language controlling the use 
of computer system resources. 

Programming support person whose re- 
sponsibilities include processing 
source statements but not writing them 
(for example, maintaining libraries, 
updating code, and producing tape 
backups) . 

Sequence of phases during which the 
software product is developed from 
concept through delivery and opera- 
tion. Also see individual phases: 
pretask planning, requirements 
analysis, preliminary design, detailed 
design, implementation, system test- 
ing, acceptance testing, and mainte- 
nance . 

Eighty-byte records that can be proc- 
essed by a compiler or assembler. 

An estimate of the number of execut- 
able lines of code developed. The sum 
of all new code plus 20 percent of the 
reused code, minus 50 percent of that 
total (estimated as the amount of com- 
ment lines) , minus 10 percent of that 
result (estimated as the amount of 
nonexecutable statements) . 
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- delivered 

\ 

- developed 

- executable 

- modified 

- new 

- old 

- reused 
load module 

logic error 

machine language 

macro 

main program 


Total number of lines of source code 
generated as a deliverable item for a 
project. Includes all executable, 
nonexecutable, and comment statements 
whether newly coded or taken from 
existing programs and library routines. 

Total number of new lines of source 
code plus 20 percent of reused code. 

Code that changes the value or state 
of a program or data. 

Previously developed code that has 
been changed for reuse in a new system. 

Total number of lines of source code 
written by programmers for a given 
task. Does not include any code that 
was taken from previously existing 
programs, but does include comments, 
executable, and nonexecutable state- 
ments . 

Total number of lines of source code 
taken from previously existing pro- 
grams and reused without change. 

See old lines of code. 

An executable program produced by 
translating and linking source code. 

Any error resulting from an incorrectly 
formulated decision or transfer. 

A system of numeric operation codes, 
values, and addresses, a sequence of 
which can be directly executed by a 
computer . 

A single instruction in a source lan- 
guage that represents a defined se- 
quence of source instructions in the 
same language. A macro is replaced by 
the sequence it represents before pro- 
gram translation. 

A program unit containing at least one 
executable statement and having a 
starting address for .program execu- 
tion; normally, the set of instruc- 
tions that determines the basic 
sequence of control. 
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maintenance 


management, software 


management, 

technical 

manpower 


The process of modifying existing op- 
erational software to correct errors 
or enhance capabilities while leaving 
its primary function intact. 

All the technical and management ac- 
tivities, decisions, and controls di- 
rectly required to purchase, develop, 
or maintain software throughout its 
life cycle. 

Planning, organization, motivation 
(direction) , and control of a tech- 
nical project and technical personnel. 

See staff-level and staff-unit. 


measure 


methodology 


metric 


A count or numerical rating of the 
occurrence of some property. Examples 
include lines of code, number of com- 
puter runs, person-hours expended, and 
degree of use of top-down design 
methodology. 

A prescribed set of principles and 
procedures for the development proc- 
ess. These principles may pertain to 
requirements, design, code, testing, 
or management. Examples include 
structured analysis, top-down design, 
information hiding, structured pro- 
gramming, formal test plans, and con- 
figuration management. 

See measure. 


microcomputer 

microprocessor 


mission date 


A class of computer based on a 
microprocessor . 

A single integrated circuit (micro- 
processing unit) that performs the 
functions of a central processing unit. 

The date that the system must be oper- 
ational, usually 2 months before 
launch . 


model Equation relating two or more quanti- 

tative factors. A resource utiliza- 
tion model may provide an estimate of 
the cost of a project; a reliability 
model may indicate when sufficient 
testing has been done. 

modification The process of altering a program and 

its specification to perform either a 
new task or a different but similar 
task . 
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modified code 
module 

module coupling 


module strength 


module test 
new lines of code 
object module 


omission error 

online processing 
operand 

operator 

operating system 


operation 


See lines of code. 

A named subroutine unit that is inde- 
pendently compilable. 

A measure of the strength of the con- 
nections between two modules in a com- 
puter program. Module independence is 
a desirable software quality. The 
levels of module coupling from lowest 
(best) to highest (worst) are data, 
stamp, control, external, common, and 
content . 

A measure of the unity of purpose or 
cooperation among the internal elements 
of a module. Module cohesion is a de- 
sirable software quality. The levels 
of module strength from highest (best) 
to lowest (worst) are functional, in- 
formational, communicational , proce- 
dural, classical, logical, and 
coincidental. 

See testing, unit. 

See lines of code. 

A computer program expressed in machine 
language, usually the result of trans- 
lating a source program by an assembler 
or compiler. 

An error made by leaving out an item 
that results in software containing a 
defect. 

Interactive processing, between humans 
and the computer . 

A symbol denoting a data item, indi- 
cator, or target of the action of an 
operator. Also see Halstead measures. 

A symbol denoting an operation, func- 
tion, or action. Also see Halstead 
measures . 

An integrated set of routines and 
services that monitor and manage sys- 
tem resources and the execution of 
application programs. 

A function that transforms data ob- 
jects from input domain (s) into data 
objects in the operation's output do- 
main (s) . 
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optimization 


overlay 

parameter 

parse 

phase 

precompiler 


preliminary design 
pretask planning 


preventive 

maintenance 

procedure 


procedural 

specification 

process design 
language 

productivity 


A change in the source code to improve 
program performance, for example, to 
make it run faster or use less space. 
Optimization changes are not error 
corrections; however,, if the change is 
made to conform to a specified re- 
quirement, the term "error" applies. 

A hierarchical structure of program 
components that allows the program to 
be executed while only part of it re- 
sides in main memory at any given time. 

A variable or measure that can take on 
more than one value, but only one at a 
time . 

To decompose a sequence of symbols 
(block, line, phrase) into a set of 
elementary subunits (words, commands, 
characters) . 

See life cycle. 

A computer program used to add special- 
purpose capabilities to a language 
system. A precompiler translates 
special features implemented as macros 
into regular instruction sequences in 
a programming language. 

See design phase. 

Planning efforts prior to the start of 
requirements analysis; generation of 
software development plans and esti- 
mates. 

Maintenance specifically intended to 
prevent faults from occurring. 

(1) A sequence of steps that accom- 
plishes some task. 

(2) A named subroutine. 

A specification of a software component 
in an algorithmic manner, stating how 
the program is to work. 

See program design language. 


A measure of the rate of production 
per unit of effort expended. 
Typically, lines of code produced per 
staff hour. 
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program 

program complexity 

program design 
language 

program listing 
program validation 
programming language 

project 

proof technique 

prototype 

quality 


A sequence of instructions that di- 
rects the computer to perform a task.. 

A measure of the number of execution 
paths in the program and the diffi- 
culty of determining the path for an 
arbitrary set of input data. Also see 
complexity . 

A language, often called pseudocode, 
used in the design and coding phases 
of a project, that contains a fixed 
set of control statements and a formal 
or informal way of defining and oper- 
ating on data structures. 

The sequence of instructions making up 
a computer program, usually in the 
form of a printout. 

All techniques used to ensure correct 
programs, including system, and sub- 
system, and system integration testing. 

A set of statements and instructions 
with a formal syntax and lexical rules; 
used in composing computer programs 
that require translation prior to 
machine execution. 

A software development effort with set 
goals and defined objectives that uses 
the technical and managerial capabili- 
ties of personnel, has a life cycle 
with fixed endpoints, and produces a 
specified product. 

A method for formally demonstrating 
that a piece of software performs ac- 
cording to its specifications. Proof 
techniques usually use some form of 
mathematical notation to describe the 
result of executing a program. 

A system developed with the intention 
of serving as a pattern for a future 
development effort. 

The degree to which software conforms 
to certain desirable characteristics. 
These may include, but are not limited 
to, correctness, reliability, usabil- 
ity, validity, efficiency, flexibil- 
ity, and maintainability. 
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quality assurance 

A planned and systematic procedure for 
ensuring that the product conforms to 
established technical requirements and 
quality standards. 

read 

The reading by peers of code and de- 
sign materials to look for errors, 
invent tests, and so on. 

real-time 

A program that receives input from a 
process or activity and reacts in time 
to affect that process or activity. 

reliability 

The probability that software will 
function without failure under stated 
conditions for a stated period of time. 

requirement 

A system specification written by the 
user to define a system to a devel- 
oper. The developer uses this speci- 
fication in designing, implementing, 
and testing the system. 

requirements 

analysis 

An analysis of the contents of the 
functional specification and require- , 
ments document from a software system 
viewpoint, to recast the requirements 
in terms suitable for software design. 
The completeness and feasibility of 
the requirements are assessed; missing 
or to-be-determined requirements are 
identified; all external interfaces 
are specified; and the initial deter- 
mination and allocation of resources 
are made. 

requirements 

testing 

The execution of a software product 
under controlled conditions to demon- 
strate that all stated or implied t re- 
quirements and performance criteria 
have been met# 

resource 

Any person, equipment, or facility 
that may be allocated to the accom- 
plishment of a task. 

resource estimation 
model 

. A model that attempts to relate meas- 
ures of staff and/or computer time to 
measures of the software problem, 
product, process, and environment. 
Models may range from simple, single 
variable equations to complex interac- 
tive software packages. 

reused code 

See lines of code. 
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review 

routine 

scheduling 

segment 

shared items 

simulated constructs 

software 

software class 

software develop- 
ment life cycle 

software engi- 
neering 

software reliability 
software testing 

source statements 


A formal meeting of several individ- 
uals for the purpose of examining de- 
sign, requirements, or code. 

A program or subprogram. 

The allocation of time and resources 
necessary to complete a given task or 
project. 

A contiguous piece of code that is 
unnamed and, hence, cannot be referred 
to as a single entity in a program 
statement. Could be one or several 
lines of a routine, subroutine, part 
of a data area, or an arbitrary con- 
tiguous section of memory. 

Data and programs accessible by sev- 
eral components, such as COMMON 
blocks, external files, and library 
subroutines . 

Statements used to s initiate structured 
control structures when the language 
to be used does not contain these 
structures. 

Computer program code and its associ- 
ated data, documentation, and opera- 
tional procedures. 

The functional type of a software 
item. The principal types are scien- 
tific, data processing, and control. 

See life cycle. 


A scientific approach to software de- 
velopment integrating proven cost- 
effective methodologies, tools, and 
techniques into a comprehensive 
procedure . 

See reliability. 

The process of exercising software in 
an attempt to detect errors that exist 
in the code. Also see formal testing. 

All statements input to a compiler. 
Includes executable statements (as- 
signment, IP, and GO TO); nonexecut- 
able statements (DIMENSION, REAL, and 
END); and comments. 
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specification 


specification- 

driven 


staf f -units 


standard 


string processing 
structure-driven 


structured code 


structured design 


structured 

programming 


A description of the input, output, 
and essential function(s) to be per- 
formed by a component of the system. 
Produced by the organization that is 
to develop the system; that is, it can 
be thought of as the contractor’s in- 
terpretation of the requirements. 

Uses the specifications of the program 
to determine test data; for example, 
generating test data by examining the 
input/output requirements and specifi- 
cations. 

Units of measurement for human effort 
expended over time. Examples include 
staff-years, staff-months, and staff- 
hours . 

Any specification that refers to the 
method of development of the source 
program itself, and not to the problem 
to be implemented; for example, using 
structured code, limiting subroutines 
to 100 lines, or prefixing all module 
names with the subsystem name. 

Operations performed on lists of char- 
acters. 

Uses the structure of the program to 
determine test data; for example, 
generating data to ensure that each 
branch of a program is executed at 
least once. 

Code that uses only a basic set of 
control structures: DO WHILE (itera- 

tion) , IF-THEN-ELSE (selection) , and 
BEGIN-END (sequence) or their deriva- 
tives (CASE, REPEAT UNTIL, etc.). 

A set of techniques for reducing the 
complexity of large new programs by 
dividing them into independent mod- 
ules. It produces a modular, hier- 
archical design consistent with 
structured coding practices. 

A set of techniques used to design, 
organize, and code programs that re- 
duces cc nplexity, improves clarity, 
facility's debugging, and simplifies 
modification. The techniques include 
top-down development and structured 
coding. 
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stub 


subprogram 

subroutine 


subsystem 
support software 
systems software 

system 

system description 

system integration 
system size 

system test 
table handler 


A "dummy" software element used in 
place of an expected functional ele- 
ment until that element becomes 
available . 

See* subroutine. 

(1) A module that is separately com- 
pilable but not independently 
executable . 

(2) A collection of program elements 
that provides a function that is 
relatively independent of the 
whole program. 

A collection of subprograms that pro- 
vides a major function and is indepen- 
dent of any other subsystem. 

All programs used in the development 
and maintenance of the delivered oper- 
ational programs. 

Software that is shared among appli- 
cation programs and facilitates or 
extends the use of system resources by 
the application programs. 

A set or arrangement of software and/ 
or hardware that together performs a 
common function. 

A document providing system base- 
lines, data flows, and processing de- 
scriptions. 

The process ot combining system com- 
ponents to produce the total system. 

(1) The number of lines of code making 
up the software of a system. 

(2) The amount of memory, including 
instructions and data required to 
execute the system without 
overlays or paging. 

The process of trying to find discrep- 
ancies between the performance of a 
system and its original objectives. 

A component that is specifically de- 
signed to generate or interpret infor- 
mation stored in a table format. 
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task 


A set of defined objectives. Multiple 
tasks are initiated to complete a 
project. Also see project. 

technical management See management. 

telemetry Data transmitted at regular intervals 

from sensors. 


test 

test plan 

test plan document 
testing 

- functional 

- structural 

- unit 


A procedure designed to verify some- 
aspect of the performance of a soft- 
ware system. 

A description of test conditions that 
includes inputs, expected outputs, 
parameter values, etc. 

A management document that describes 
how and when specified test objectives 
will be met for the formal test plan. 

Software development activity in which 
a software system is subjected to 
specific conditions to show that it 
meets the intended design. Also see 
acceptance testing and system testing. 

Testing designed to demonstrate a 
specific functional capability of a 
program or software system. 

Testing designed to ensure that every 
path through the software is executed. 

Test of a set of program statements 
treated logically as a whole. A unit 
is usually a component, subroutine, or 
module . 


timesharing A mode of operation that provides for 

the interleaving of two or more inde- 
pendent processes on one functional 
unit . 

tool A software aid used to facilitate the 

work of development team members; for 
example, text editors, precompilers, 
code auditors, and test generators. 

top-down development The design and implementation of the 

system by starting with the highest 
level component and developing the 
components on each successive level in 
turn. 


top-down testing Testing of modules in the top-down 

order in which they were produced. 
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tree chart 

uncertainty 

unit 

unit test 
user 

user-def ined 
user's guide 
utility 

validation 


verification 


walk-through 


work-around 


An acyclic connected graph, often rep- 
resenting a hierarchy in which the 
edges are directed to denote a subor- 
dinating relationship between the 
joined nodes. 

The probability of error, or the 
probable magnitude of error. 

A set of computer program statements 
treated logically as a whole; usually 
a module or subroutine. Also see com- 
ponent, subroutine, and module. 

See testing, unit. 

The individual at the man/machine in- 
terface who is applying the software 
to the solution of a problem. 

A parameter determined by the user as 
input during program execution. 

A document designed to assist the user 
in operating the software product. 

Any component that is generated to 
satisfy some general support function 
required by other applications soft- 
ware . 

The process of determining whether a 
software product satifies its intended 
function regardless of whether or not 
it meets its requirements and speci- 
fications . 

The process of determining whether a 
software product meets its formal re- 
quirements and specifications. 

A formal meeting for the review of 
source code and/or design by project 
members for the purpose of error de- 
tection, not correction. 

The process or result of counteracting 
the effects of an error in a program 
when the cause of the error and, con- 
sequently,. the location of the state- 
ments containing the error is not 
known or is inaccessible; for example, 
a compiler error. 
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work unit 


A measure of software size for which 
the effort required is known or can be 
approximated. A project is broken 
down into work units to facilitate 
cost estimation. Some common work 
units include the number of require- 
ments, programs, subsystems, modules, 
pages of documentation, and lines of 
code . 
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SECTION 3 - ACRONYMS 



ACC 

ALC 

ATR 

BMDP 

CAREM 

CAT 

CDR 

CIF 

CMT 

COCOMO 

CRP 

CSC 

CSF 

CSR 

DAIO 

DARES 

DBA 

DBAM 

DLOC 

FTIO 

GESS 

GSFC 

HDR 

HIPO 

HIS 

IV&V 

JCL 

LOC 

MPP 

MTTF 

ORR 

PANVALET 


Accounting Information File 

Assembly Language Code 

Assistant Technical Representative 

Biomedical Programs, P Series 

Cost and Reliability Estimating Models 

Configuration Analysis Tool 

Critical Design Review 

Component Information File 

Comment File 

Constructive Cost Model 

Change Report Form 

Computer Sciences Corporation 

Component Summary Form 

Component Status Report 

Direct Access Input/Output Program 

Data Base Retrieval System 

Data Base Administrator 

Data Base Maintenance System 

Developed Lines of Code 

FORTRAN Input/Output Program 

Graphic Executive Support System 

Goddard Space Flight Center 

Project Header File 

Hierarchical Input Processing Output 
Growth History File 

Independent Verification and Validation 
Job Control Language 
Lines of Code 

Modern Programming Practices 
Mean Time to Failure 
Operational Readiness Review 

Computer Program Analysis and Security System 
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PDL 

PDR 

PRICE-S 

RAP 

RSP 

SAP 

SAS 

SEF 

SEL 

SFORT 

SLIM 

SRR 

STL 

TBD 

TSO. 

UM 


Program/Process Design Language 
Preliminary Design Review 

Programmed Review of Information for costing 
and Evaluation Software Model 

Run Analysis Form 

Resource Summary Form 

FORTRAN Static source Code Analyzer Program 

Statistical Analysis System 

Subjective Evaluations File 

Software Engineering Laboratory 

Structured FORTRAN Preprocessor 

Software Life-Cycle Management Estimating Model 

System Requirements Review 

Systems Technology Laboratory 

To Be Determined 

IEM Timesharing Option 

University of Maryland 
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